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Small Computer System Supports 
Large-Scale Multi-User APL 

Powerful, interactive APL is now available for the multi- 
lingual HP 3000 Series II Computer System. A special 
terminal displays the APL character set. 

by Kenneth A. Van Bree 



APL (A PROGRAMMING LANGUAGE) is an 
interactive language that allows access to the full 
power of a large computer while maintaining a user 
interface as friendly as a desktop calculator. APL 
is based on a notation developed by Dr. Kenneth 
Iverson 1 of IBM Corporation over a decade ago, and 
has been growing in popularity in both the business 
and scientific community. The popularity of APL 
stems from its powerful primitive operations and 
data structures, coupled with its ease of programming 
and debugging. 

Most versions of APL to date have been on large and 
therefore expensive computers. Because of the ex- 
pense involved in owning a computer large enough to 
run APL, most of the use of APL outside of IBM has 
been through commercial timesharing companies. 
The introduction of APL \3000 marks the first time a 
large-machine APL has been available on a small 
computer. APL \3000 is a combination of software for 
the HP 3000 Series II Computer System 2 and a CRT 
terminal, the HP 2641A, that displays the special 
symbols used in APL. The terminal is described in the 
article beginning on page 25. 

Although the HP 3000 is normally considered a 
small computer, APL\3000 is not a small version of 
the APL language (see pagel4). As a matter of fact, 
APL\3000 has many features that have never been 
available before, even on the large computers. For 
example, although APL\3000 looks to the user just 
like an interpreter, it is actually a dynamic compiler. 
Code is compiled for each statement as it is encoun- 
tered; on subsequent executions of the statement, if 
the compiled code is valid, it is re-executed. By 
eliminating the interpretive overhead, a speedup on 
the order of a factor of ten can be obtained in some 
cases, although the speedup is dependent on the 
amount of computation involved in the statement. 

The basic data type of APL is an array, which is an 
ordered collection of numbers or characters. Sub- 
script calculus, as defined by Philip Abrams, 3 is a 
method of selecting portions of an array by man- 
ipulating the descriptors that tell how the array is 
stored. The use of subscript calculus in the dynamic 



compiler allows computation to be avoided in many 
cases, and eliminates the need for many temporary 
variables to store intermediate results. 

One problem that has always plagued APL users is 
the limited size of most APL workspaces. A work- 
space in APL is a named data area that contains all the 
data variables and functions that relate to a particular 
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D Compute boi 


nd large workspace swapping program 


B Edit simple calculation program and execute. E Compute bou 


nd simple calculations 


C Assignments and addition in calculate 


mode F Compute bou 


nd primes program. 



Fig. 1. Average response times 
for a range of activities on an HP 
3000 Series II System used only 
for APL and similar data for a 
range of APL activities on a multi- 
lingual HP 3000 Series II System. 
A system with 51 2K bytes of main 
memory will support up to 16 APL 
terminals. 



problem or application. Most other APL systems limit 
a workspace to 100,000 bytes or less. APL\3000 
eliminates this limitation by giving each user a vir- 
tual workspace. A workspace is limited only by the 
amount of on-line disc storage available. 

APIA3000 is the first APL system to include 
APLGOL 4 as an integral part. APLGOL is a block- 
structured language that uses keywords to control the 
program flow between APL statements. To facilitate the 
editing of APLGOL programs, and to provide an en- 
hanced style of editing for APL programs and user data, 
a new editor was added to the APL system. This editor 
can be used on both programs and character data, and 
includes many features never available before in APL. 

One of the features of APL that makes program de- 
velopment easier is that program debugging can be 
done interactively. When an error is encountered in an 
APL program, an error message is displayed along with 
a pointer to the place where the error was detected. 
Execution is suspended at this point, and control is 
returned to the user. In other versions of APL, the user is 
allowed to reference or change only the variables that 
are accessible within the function in which the error 
occurred, and must resume execution within that func- 
tion. APL\3000 has implemented a set of extended 
control functions that allow the user to access or change 



any variable in the workspace and resume execution 
within any function that has not yet completed execu- 
tion. These extended control functions can be used to 
implement advanced programming techniques that 
were previously difficult or impossible to implement in 
APL. An example is backtracking, which involves sav- 
ing the control state at various points in the computa- 
tion and returning to a previously saved control state 
when an error is detected. 

The new features of APL \3000 are described in detail 
in the articles that follow. 

Performance Data 

An HP 3000 Series II System with 512K bytes of main 
memory will support a maximum of 16 terminals using 
APL, or a combination of terminals using APL and other 
languages. Fig. 1 shows typical response times for vari- 
ous combinations of terminal types, APL program 
loads, and memory sizes. 
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Introduction to APL 



APL (an abbreviation for A Programming Language) is a 
concise high-level language noted for its rich variety of built-in 
(primitive) functions and operators, each represented by a 
symbol, and its exceptional facility for manipulating arrays. 

APL uses powerful symbols in shorthand fashion to define 
complete functions in very few statements or characters. For 
example, the sums of each of the rows in a very large table 
called T are +/T. The sums of the columns are + /[1]T. The 
grand total of all numbers in the table is simply + /,T. Sorting 
and adding tables and other common operations are just as 
simple. 

These characteristics, combined with minimal data declara- 
tion or other language requirements, help substantially reduce 
programming effort. Typical interactive APL programs take only 
10-30% as long to write as would equivalent programs in other 
languages, such as FORTRAN or BASIC. 

APL was invented by Dr. Kenneth E. Iverson at Harvard Uni- 
versity. In 1962 a description of his mathematical notation was 
published. By 1966, IBM had refined the notation into a lan- 
guage and implemented the first version of APL on an experi- 
mental timesharing system. By 1969 APL was an IBM program 
product and several independent timesharing services began 
providing it. 

Because APL is both easy to use and tremendously powerful 
it has gained widespread acceptance. A large, swiftly growing 
APL timesharing industry has developed. Approximately 70% of 
IBM's internal timesharing is done in APL. Over 50 North Ameri- 
can universities including Yale, MIT, UCLA, Syracuse, Univer- 
sity of Massachusetts (Amherst), York, and Wharton have in- 
house systems. Popularity has grown in Europe, especially 
Scandanavia and France. 



Although initially designed for scientific environments, APL's 
features proved to be ideal for processing business data in 
tabular formats. Now, most timesharing services find approxi- 
mately 80% of their APL business is in the commercial applica- 
tions area. 



APL Characteristics 

A symbolic language with a large number of powerful primitive func- 
tions. 

Uses right to left hierarchy (as opposed to precedence) that can be 
overridden by parentheses. 

Designed to deal with arrays of numbers as easily as other languages 
deal with individual items. 

Minimum language constraints: very few syntax rules; uniform rules 
for all data types and representations; automatic management of 
data storage and representation. 

APL Advantages 

Programs can be developed in 10-30% of the time and code space 
required by languages like FORTRAN, ALGOL, and BASIC. 
Concepts of a program can often be more quickly grasped because 
of the brevity and conciseness of APL code. 
Very flexible: programs easy to change; data very accessible and 
easy to rearrange. 

Fig. 1. Characteristics and advantages of APL 



BASIC 

10 DIM A(100) 

20 READ N 

30S=0 

40 FOR 1 = 1 TON 

50 READ A(l) 

60S=S+A(I) 

70 NEXT I 

80 PRINTS 

90 END 



FORTRAN 

DIMENSION A (100) 

READ (5,10) N 
10 FORMAT (13) 

READ (5,20) (A(l), l= 
20 FORMAT (8E10.3) 

S=0.0 

DO 30 1 = 1, N 
30S=S+A(I) 

WRITE (6,40)S 
40 FORMAT (E12.3) 

END 



1. N) 



ALGOL 

REAL S; 
INTEGER I, N; 
GETN; 
BEGIN 

REAL ARRAY A(1:N); 
S:=0.0; 

FOR l: = 1 TO N DO 
BEGIN 
GET A(l); 
S:=S+A(I); 
END; 
PUTS; 
END; 



APL 

+ /,A«-D 



Fig. 2. Comparison of steps required to read and sum a list of numbers. 



R = Revenues by product and salesman 
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Given: 



E = Expenses by product and salesman 





Johnver 


Vanston 


Danbree 


Vansey t 


Mundyke 


Tea 


120 


65 


890 


54 


430 


Coffee 


300 


10 


23 


802 


235 


Water 


50 


299 


1290 


12 


145 


Milk 


67 


254 


89 


129 


76 



Find: 



Find each salesman's total commission where the formula for 
commission is 6.2% of profit, no commission for any product 
to total less than zero. 



Answer: 



Commission 



Johnver 
92 



Vanston 
5 



Danbree 
113 



Vansey 
45 



Mundyke 
32 



Explanation of APL Code Required: 



.062 x + / 

A A 



R-E 



t 



Stepl. Subtract each item in matrix E from each item in matrix R 

Step 2. Find maximum of each item in resultant matrix versus the value of zero 

Step 3. Sum over new resultant matrix by rows 

Step 4. Multiply individual items in resultant vector by .062 

Step 5. Automatically print new resultant vector 



Comparison of APL Code Required With BASIC Code Required 
APL 



.062 x +/ Of R-E 



BASIC 

10 FILES DATA 

20 DIMENSION R(4,5), E(4,5), T(5) 

30 MAT READ #1; R,E 

40 MAT T = ZER 

50 FOR P = 1 TO 4 

60 FOR S = 1 TO 5 

70 T(S) = T(S) + .062.(R(P,S)-E(P,S))MAX0 

80 NEXT S 

90 NEXT P 
100 MAT PRINT T 
110 END 



Fig. 3. Explanation of APL code using typical example 



APL Data: Virtual Workspaces and 
Shared Storage 



by Grant J. Munsey 



MUCH OF THE POPULARITY of APL can be 
attributed to the convenient way it handles 
data. Most other programming languages treat vari- 
ables as volatile "scratchpad" areas that are occupied 
by meaningful data only while programs are execut- 
ing. Before programs can run, they must load the 
variables with data, usually by reading a file. During 
program execution the data is accessed by referring 
to variable names. When execution is completed, 
the meanings of the variables are lost unless the pro- 
grams explicitly save their data in another file. APL, 
on the other hand, provides direct access to named 
data items, large or small, without forcing the con- 
cept of a file on the programmer. Once values are 
assigned to APL variables, they are accessible by 
name either in program execution mode or in calcula- 
tor mode. The relationship between the data and the 
name is preserved until the programmer chooses to 
purge the data. The variables and the functions that 
operate upon them are preserved together, which 
means that APL applications need not go to files to 
access and save data. 

In APL a unique name is attached to each distinct 
set of data by means of the assignment arrow: 

DATE<-7 4 1776 

OCCASION^ 'independence day' 

APL\3000 variables may be either scalar (single- 
element) or array-shaped with up to 63 dimensions. 
Though conceptually there are only two data types in 
APL, character and numeric, APL\3000 actually 
stores its data in a variety of ways for efficiency. APL 
differs from most other programming languages in 
that an APL programmer is never involved in specify- 
ing or choosing these machine-dependent internal 
representations; the APL system automatically 
chooses both the most efficient and the most accurate 
representation for any given set of data. 

Likewise, an APL programmer never writes decla- 
rations specifying the shape, size, or amount of stor- 
age that will be required for a variable. Variables are 
declared by assigning data to them, and the APL sys- 
tem allocates the appropriate storage in which to re- 
tain the data. Readers familiar with languages requir- 
ing declaration of variables (e.g., FORTRAN, BASIC, 
COBOL) will recognize that the task of setting up such 
declarations can often take a substantial amount of 
programming time. 

An interesting and useful feature of APL is that a 



particular variable name may, at different points in 
time, refer to different types and shapes of data, as the 
following sequence illustrates: 

A^3.5 

A«-2 4 6 8 

A^'WHAT WOULD WE APPRECIATE?' 

A^2 3pl23456 

A 
12 3 
4 5 6 

In this example, A is first assigned the numeric scalar 
3.5. Then A is assigned the numeric vector 2 4 6 8. 
Next, A is assigned the character vector 'what WOULD 
WE APPRECIATE?'. Finally, A is assigned a two-row, 
three-column array of numbers, then printed. Notice 
that each statement whose result is not explicitly as- 
signed causes the result to be automatically printed. 

The Workspace Concept 

As functions and data are created, they remain as- 
sociated with their user-assigned names in an area 
called the active workspace. This area can be named 
and saved for later use by entering the system com- 
mand: 

)SAVE WSID 
where WSID is a user-specified workspace name. This 
saves a "snapshot" of all currently defined functions 
and data items. A saved workspace may be later re- 
activated by entering the system command: 
JLOAD WSID 

The concept of workspaces provides a convenient 
means for working on several different problems, 
each of which has its own set of pertinent data. For 
example, an accountant might have several custom- 
ers for whom he is keeping payrolls. Several work- 
spaces might be maintained, each containing payroll 
information for a particular client. Whenever a salary 
report is needed for a client, the appropriate work- 
space could simply be loaded and the report gener- 
ated. Notice that workspaces are much like folders in 
a filing system; each holds the information required 
for a specific job. 

Since all functions and data for a problem are stored 
in a single workspace, workspaces tend to grow very 
large as problem size increases. Yet most existing 
APL implementations have limited the size of work- 
spaces, typically to less than 100,000 bytes. This con- 
straint either imposes an artificial limit on the size of 



applications attempted, or forces the more deter- 
mined programmer to seek additional storage outside 
of the workspace by explicit use of a file system, a 
definite violation of the general spirit of APL pro- 
gramming. 

The HP 3000 is a small computer with a limited 
amount of main storage. Yet APL\3000 has avoided 
the traditional workspace size restrictions by employ- 
ing two strategies: shared data storage and virtual 
workspaces. 

Shared Data Storage 

Shared data storage helps solve the workspace size 
problem by conserving storage. Multiple copies of the 
same data are avoided in many cases by allowing 
arbitrary numbers of variables to share the same data 
area. Consider the following two statements: 

A<- 1 2 5 6 9 10 

The first statement creates a data area for A, while the 
second specifies that B is to be assigned whatever is in 
A. While one could naively make a second copy of the 
data and attach it to B, this is completely unnecessary 
and is a waste of storage; B should be able to share the 
original data with A. 

A potential problem is: if A and B share the same 
data area, what happens if either of the variables 
changes part of its values? Does this affect the other 
variable? For instance, the subscripted assignment 

B[3]^20 

should not have the effect of also making a[3]'s value 

20. 

Copy-on-Write 

APL\3000 solves this problem by attaching a re- 
ference count to every data area, and keeping track of 
how many variables are referring to it. Partial changes 
to a data area (e.g., B[3]<-2o) are allowed only if its 
reference count is 1 (i.e., it is unshared). A data area 
whose reference count is greater than 1 is never 
changed, since more than one variable is referring to 
it. Instead, a "copy-on-write" policy is adopted: the 
variable to be written into is given its own private 
copy of the data, the reference count of the original 
shared data area is decreased by 1, and the original 
data remains unchanged. 

Shared data storage is useful in that it frequently 
allows the APL system to avoid making multiple 
copies of identical data. But this is really only a wel- 
comed side effect of the real purpose of shared stor- 
age: allowing the dynamic compiler to implement 
certain selection functions and operators by applying 
Abrams' subscript calculus. 2 This technique is used 
to improve the performance of APL \3000, providing 
a two-fold justification of shared storage: space and 
speed. 



Subscript calculus places another requirement on 
the APL system besides shared data areas: a variable's 
data area must be decoupled from its accessing in- 
formation. That is, the data area itself must not de- 
scribe the method of storing the data therein. To un- 
derstand why this is required to perform subscript 
calculus, the attributes of APL data must be recalled: 
it has some actual collection of values, and it has a 
particular size and shape. Consider a numeric vari- 
able ABC whose data is arranged in two rows and three 
columns: 
ABC 

12 4 
5 9 

The storage for ABC contains six data elements that the 
user thinks of as a two-dimensional array. At the 
machine level, however, storage is actually accessed 
in a linear fashion , as if it were a vector. To access any 
given element of ABC, the APL system takes a set of 
user indexes, consisting of a number for each dimen- 
sion in ABC, and calculates a linear address into the 
data area holding ABC's values. 

It has been common practice to store data in what is 
called row major order. In this scheme, data is stored 
with the rightmost subscript varying the fastest. For 
example, the actual linear layout of the variable ABC 
stored in this order would be: 

12 4 5 9 

ABC[0;0] ABC[0;l] ABC[0;2] ABC[l;0] ABC[l;l] ABC[l;2] 

Notice that zero-origin indexing was used (the first 
element in any dimension is index 0). Zero origin will 
be used in all formulas and examples hereafter. 

When data is stored in row major order, one can 
map a set of user indexes into a machine address by 
employing the formula: 1 

RANK-l RANK-1 

ADDRESS = £ l[j] x f] SHAPE [K] (1) 

] = K = J + 1 

where I is the set of user indexes. In addition to the 
user indexes, this formula requires some information 
about the data's exact size and shape: RANK is the 
number of dimensions in the array, and SHAPE is a 
vector of the sizes of each of the dimensions . Together 
RANK and SHAPE make up the variable's row major 
access information. 

Applying equation 1 to calculate the actual address 
of the element ABC [o;2]: 

I : 2 

RANK : 2 

SHAPE : 2 3 

ADDRESS = (l[o] x SHAPE [l]) + (l[l] x 1) 

= (0 x 3) + (2 x 1) 

= 2 

Referring back to the description of how ABC is 
stored, it can be seen that ABC [o;2] is indeed at loca- 
tion 2. Thus for data stored in row major order, all that 



is needed to calculate the actual storage address of an 
array element from a set of user indexes is the RANK 
and SHAPE of the data. 

In APL systems not concerned with performing 
subscript calculus, this accessing information is tra- 
ditionally stored with the data itself, which makes 
every data area self-describing. Subscript calculus, on 
the other hand, wants to view data in many different 
ways without physically rearranging it. The opera- 
tion of subscripting (e.g., ABC [l;l]), and the functions 
TAKE, DROP, REVERSAL, TRANSPOSE, and RESHAPE can be 
implemented so that they rearrange data without ac- 
tually moving or copying it, but only if the data area's 
accessing information is not an integral part of the 
data. Consider, for example, the APL function that 
reverses the columns of an array. 

ABC 

12 4 
5 9 

RABC^(j)ABC 

RABC 

4 2 1 
9 5 

If the result of the reversal must always be stored in 
row major order, then nothing can be done except to 
make a second copy of ABC's data for RABC, with its 
order rearranged. But if one can depart from row 
major storage order in this case, one can generate new 
access information for RABC, and it can share ABC's 
data area with no data movement required. This re- 
quires generalizing the storage mapping function de- 
veloped above to allow other storage arrangements 
than row major. The new formula will be: 

RANK-l 

ADDRESS = OFFSET + £ l [J] x DEL M ( 2 ) 

I = o 
This generalized formula makes explicit something 
that equation 1 was able to imply by knowing that 
data was stored in row major order: OFFSET is always 
zero; and DEL [j] is always 

RANK-l 

f] SHAPE [K], 

K = J+1 

The new formula requires that both of these be 
made part of a variable's data accessing information. 
Equation 2 can be checked by again calculating the 
address of element ABC [o;2]: 



I 

RANK 

SHAPE 

DEL 

OFFSET 



2 
2 

2 3 

3 1 





tion 1, so equation 2 seems to work, at least on row 
major data. This new formula can be used to share 
ABC's data with RABC: 

12 4 5 9 

ABC[0;0] ABC[0;l] ABC[0;2] ABC[l;0] ABC[l;l] ABC[l;2] 
RABC [0:2] RABC [0;l] RABC [0;0] RABC [l;2] RABC [l;l] RABC [l;0] 

By changing both the DEL vector and the OFFSET as 
shown below, RABC can be totally described by its 
accessing information. As a check, equation 2 can be 
used to calculate the storage address of element RABC 

[0;2]: 

2 



I 

RANK 

SHAPE 

DEL 

OFFSET 



ADDRESS = OFFSET + (l[o] x DEL [o]) + (l[l] x DEL [l]) 
= + (0 x 3) + (2 X 1) 
= 2 

This is the same address calculated by applying equa- 



ADDRESS = OFFSET + (l[o] x DEL [o]) + (l[l] x DEL [l]) 
= 2 + (0 X 3) + (2 X (-1)) 
= 

Referring back to the data area shared by ABC and 
RABC, it can be seen that RABC [o;2] is indeed at address 
of the shared data area. 

Thus by including the DEL vector and the OFFSET in 
a variable's set of accessing information, data areas 
can be shared among variables whose conceptual or- 
derings differ. Notice, though, that each variable must 
have its own private set of accessing information for 
this to work, otherwise the shared data area can only 
be interpreted as one shape and storage method. 
Using a set of transformations to the DEL vector and 
the offset in the above manner to rearrange data 
without actually moving it is the essence of subscript 
calculus. 

Virtual Workspaces 

The WS FULL message is well-known to most APL 
programmers. In specific terms, it means that the ac- 
tive workspace has filled up and program execution 
has stopped. In more general terms, it usually means 
that the programmer is going to have to do a lot of 
work to circumvent the problems of limited work- 
space size. 

APL\3000 uses a technique called virtual storage 
to remove the workspace size limit. This allows the 
user to create and maintain workspaces containing 
millions of bytes of data. In fact, workspaces are lim- 
ited in size only by the amount of disc storage avail- 
able on the machine, the same limit that would apply 
to data stored explicitly as files. 

Two layers of virtual workspace implementation 
make this possible. The first layer creates, by means of 
microcode routines, a very large linearly addressed 
data space. The second layer maintains this address 
space in many smaller variable-length segments. 

To provide the large address space required to sup- 
port virtual workspaces, APL \3000 uses a set of nine 
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Fig. 1 . APL 3000 uses a virtual memory scheme to give each 
user whatever size workspace is needed, instead of imposing 
a fixed maximum workspace size as most APL systems do. 
The virtual memory is partitioned into 2 M pages of 2 N words 
each where N+M = 32. 

virtual memory instructions that have been added to 
the HP 3000 Series II instruction set. These instruc- 
tions are added by installing eight read-only memory 
(ROM) integrated circuits in the CPU when APL \ 3 000 
is installed. The virtual memory instructions take a 
small amount of main computer storage plus a large 
disc file and create what looks like one large linearly 
addressed memory. This is done using what is known 
as a least recently used (LRU) virtual memory scheme. 

The logical addresses used by APL\3000 are 32-bit 
quantities. The M most significant bits of the address 
are considered the page address and the N least sig- 
nificant bits the word-in-page address. Thus the vir- 
tual memory is partitioned into 2 M pages of 2 N 
words each (see Fig. 1). The values for N and M are 
determined by APL\3000 to provide efficient use of 
the computer hardware. N plus M must add up to 32, 
so the virtual memory can contain up to 2 32 words 
(4,294,967,296 words). This is the only theoretical 
limit to workspace size. 

The HP 3000 main computer store is set up to con- 
tain a number of 2 N -word pages from the virtual mem- 
ory along with a small status table for each main- 
store-resident page. Each status table contains the 
following information: 

The virtual memory address of the first word in 

the page 



A link that points to the next status table 

An indicator that tells whether data in the page 

has been modified since the page was brought into 

main storage from the disc 

The main storage address of the words in the page. 

Fig. 2 shows how these status tables are arranged in 
main store along with the data from the pages. The 
status tables are arranged in a list with each status 
table pointing to the next status table. This list is 
always arranged so the status table for the most re- 
cently used page is the first entry in the list. 

Operation of the virtual memory instructions can 
be illustrated by describing the execution of a VIRTUAL 
LOAD instruction (see Fig. 3). This instruction re- 
quires a 32-bit virtual address as its operand and 
returns the word stored at that location in virtual 
memory. To accomplish this the first task is to deter- 
mine the page in which the word resides (the page 
address). This is done by taking the M most signifi- 
cant bits of the virtual memory address. The second 
operation is to find where the required page resides. 
This is done by first searching down the list of status 
tables to see if the page is in main storage. If the page 
is found in the list then the word requested is already 
in main storage and all that need be done is to use the 
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Fig. 2. At a given time, the main computer store contains a 
number of 2 N -word pages from the virtual memory along with a 
small status table for each of these pages. The status tables 
are arranged in a list with the table for the most recently 
accessed page at the top of the list. 



Starting Virtual Memory 
Address of Page 

Pointer to Next 
Status Table 




Fig. 3. If the page that contains the word addressed is not in 
main storage, the system brings in the required page from the 
disc, swapping it for the page whose status table is at the 
bottom of the list, that is, the least recently used page. 

word-in-page part of the virtual address to access it. If 
the end of the status table list is reached without 
encountering the required page then a software 
routine is called from the virtual instruction mi- 
crocode. This routine decides which of the current 
main-store-resident pages can be overwritten with 
the data from the new page, stores the current page on 
the disc if it has been altered since being loaded, and 
reads in the new page. 

APL\3000 always chooses the least recently used 
page as the one that can be removed. This is the page 
whose status table is the last one in the status table 
list, since the list is maintained with the most recently 
used page first. This method is critical to the efficient 
operation of virtual memory, because it causes the 
pages that are used frequently by APL\3000 to re- 
main in main storage where they can be rapidly ac- 
cessed while the infrequently used pages migrate to 
the disc. 

Virtual Segmentation 

For this large linearly addressable virtual memory 
to be useful in creating virtual workspaces the ad- 
dress space must be broken up into several small 
blocks of memory, each of which can be indepen- 
dently expanded or contracted in size. In APL\3000 
this is accomplished by three software routines. The 



first routine allocates blocks of memory; it is given the 
required number of words and it returns the starting 
virtual address of the block allocated. The second 
routine returns previously allocated blocks of mem- 
ory to the free list where they are available for later 
reallocation. The third routine can be instructed to 
expand or contract the size of a currently allocated 
block of memory. 

The virtual storage allocation routines work with a 
data structure called the free storage list (FSL). The 
FSL contains an entry for each block of unused stor- 
age in the virtual workspace. Each entry in the FSL 
contains the following items: 

A 32-bit virtual memory address that is the begin- 
ning of a free block of virtual memory 
The number of words in the free block of memory. 
When a block of storage is returned to the FSL by 
the software a description of the block is put into the 
FSL so that no two FSL entries describe adjacent areas 
of memory. In this way the free storage available in a 
workspace is represented by the minimum number of 
FSL entries. 
Conclusion 

APL is a convenient language because its work- 
space concept allows the programmer to use variables 
rather than files. APL\3000 has extended its useful- 
ness by allowing workspaces to be extremely large. 
Also, storage use and speed have been optimized by 
means of shared data areas and subscript calculus. 
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APLGOL: Structured Programming 
Facilities for APL 



by Ronald L. Johnston 



OVER A PERIOD OF YEARS the computer science 
community has developed a set of programming 
disciplines for systematic program design that have 
become widely known as structured programming. 
One very important component of this science is a set 
of interstatement control structures for clearly ex- 
pressing the flow of control. These control structures 
are embodied in such block-structured languages as 
ALGOL or PASCAL, and therefore these languages 
have been widely used in teaching computer science 
in colleges and universities. One control structure 
that has received much criticism as unstructured 
and harmful is the GOTO of FORTRAN and other 
languages. 1,7 ' B The use of the GOTO, it is argued, is 
to be avoided because it can render program flow 
unintelligible, unmaintainable, and impossible to 
prove correct. 

APL is a modern language with array-oriented 
functions, but only a single branching construct is 
available: ^expression, where "expression," how- 
ever complex, evaluates to a statement number to 
which control is transferred. This construct is the 
rough equivalent of a computed GOTO which, as men- 
tioned previously, is not considered a good struc- 
tured programming tool. Many APL enthusiasts, in 
defense of the language, have argued that its rich set 
of array functions reduces the necessity of including 
explicit loop constructs in an APL program, thereby 
minimizing the importance of good control structures 
in this particular language. Nevertheless, empirical 
studies 2 of APL programs have shown that the fre- 
quency of branching per line is greater in APL than in 
FORTRAN, although there are fewer branches per 
equivalent function. Furthermore, as a consequence 
of having only one branching construct the control 
flow even within well structured APL programs can 
often be obscure. 

Many attempts have been made to improve the 
readability and understandability of the APL branch 
function. Saal and Weiss 2 relate that APL program- 
mers use various stylized forms of branching with 
great frequency in an attempt to impart some regular- 
ity to the branch construct. These constructs have 
become much-used idioms of the language. Other 
APL programmers, 3 ' 4,5 dissatisfied with even these 



stylized branching constructs, have invented special 
packages of APL functions that attempt to provide 
more acceptable control structures like IF-THEN-ELSE, 
WHILE-DO, CASE, and REPEAT-UNTIL. However, these 
special functions have discouraged their own use be- 
cause they occupied storage in workspaces that were 
already too small, and because the function calls im- 
posed a run-time speed penalty on the user. The only 
acceptable solution lay in enhancing the language 
itself, so that APL programmers could use the grow- 
ing body of structured programming techniques 
without incurring the penalties inherent in the solu- 
tions to date. 

Solution: APLGOL 

APL\3000 includes an alternate language, 
APLGOL, which enhances standard APL in the area of 
branching. Based on the work of Kelley and Walters 6 , 
APLGOL is a fully-supported language that adds 
ALGOL-like control structures to APL to provide the 
needed structured programming facilities. Program- 
mers writing in APLGOL can make use of such famil- 
iar constructs as IF-THEN-ELSE, WHILE-DO, REPEAT- 
UNTIL, and CASE. Some constrained forms of struc- 
tured branching are also included; they are LEAVE, 
ITERATE, and RESTART. The resultant programs are 
much easier to read, understand, and maintain than 
the equivalent programs written in standard APL. 
These qualities are essential in production pro- 
gramming environments. 

Another language facility, ASSERT, has been incor- 
porated to encourage programmers to assert correct- 
ness properties of algorithms as they write them, 
hopefully to foster the proof-of-correctness approach 
to programming that Dijkstra has recognized as so 
important to the production of error-free pro- 
grams. 8,9,1 ° Using ASSERT statements the pro- 
grammer states properties and conditions that must 
be true if the program being written is to work prop- 
erly. For example, suppose a function uses the vari- 
able A as a divisor and the programmer expects that 
no element of A should ever be zero. The following 
assertion might be included in the function ahead of 
the division: 

ASSERT 1: A/A^O; 
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LlSTFNS:LlSTFNS;FNL;FNAME:DlO;NLINES;INX 

fl PRINTS TEXT OF ALL FUNCTIONS IN WORKSPACE EXCEPT ITSELF 

QlO-o 

FNL^FNL[Ab51^DaV 1 FNL*-DNL 3 4;] A GET SORTED FNS LIST 

->(0/x/pFNL)/HAVEFNS 

U-'(NO FUNCTIONS IN WORKSPACE)' 

^0 
HAVEFNS: D-' )FNS',0r„FNL,' '« PRINT )FNS LIST 

[NX- 
NEXTNAME: ^(INX>lTpFNL)/0 

FNAME^(FNAME^' ')/FNAME*-,FNL[lNX;] fl DE-BLANK NAME 

D«-(2pDR). '*•**• '.FNAME.' •-..•' 

NLlNES-lfpCR-QCR FNAME n GENERATE CANONICAL REP 

D- '['.((([lO»NLINES),0)T(NLINES,l)p 1 NLINES),']',' '.CR 

INX— INX + 1 

^NEXTNAME 



PROCEDURE LISTFNS.LISTFNS,FNL,FNAME,GlO,NLINES.INX; 

fl PRINTS TEXT OF ALL FUNCTIONS IN WORKSPACE EXCEPT ITSELF A 
DlO- 0; 

FNL~FNL[465lS[]AVlFNL-[]NL 3 4;]; n GET SORTED FNS LIST n 
IF 0= x/pFNL THEN 

Q«-'(NO FUNCTIONS IN WORKSPACE)' 
ELSE 
BEGIN 

D*-' )FNS',Qr„FNL,' '; fl PRINT )FNS LIST fl 

INX-0; 

WHILE INX<lTpFNL DO 
BEGIN 
FNAME-(FNAME^' ')/FNAME-,FNL[lNX;]; n DE-BLANK NAME F 
D-(2pDR). '***" '.FNAME,' .•«•«'; 

NLINES-lTpCR-QCR FNAME; p GENERATE CANONICAL REP R 
D^'[',(((flO«iNLINES),0)»(NLINES,l)plNI.INES),']', 1 '.CR; 
INX-INX + 1; 
END; 
END; 
END PROCEDURE 



Fig. 1. An APL function and its APLGOL counterpart. Thetwo 
functions are nearly identical, but the APLGOL function makes 
use of ALGOL-like control structures that make it easier to 
read, understand, and maintain. 



In this fashion the programmer lets the correctness 
proof and the program grow hand in hand. Each AS- 
SERT statement contains a relational expression that is 
evaluated dynamically each time control reaches it. If 
the assertion proves false, execution is halted to per- 
mit the programmer to choose an appropriate course 
of action. Assertion statements can be conditionally 
executed, based on a level number in each assertion. 
One useful way to employ assertions is to have all 
assertions checked during initial program writing 
and debugging. Later, as the program reaches produc- 
tion status, assertion checking is turned off. If at some 
future date the program exhibits erroneous behavior, 
checking of assertions can be easily reinitiated, 
greatly facilitating debugging efforts. Using asser- 
tions in this fashion, there is no run-time penalty 
during production use of the programs; only during 
debugging stages are the assertions checked. 

A workspace may contain both APL and APLGOL 



functions, which may call each other without restric- 
tion. (However, any given function must be entirely 
APL or entirely APLGOL.) APLGOL expressions are 
exactly the same as APL expressions, following the 
same set of syntax and semantic rules. A function 
originally developed in APL can be easily modified to 
become an APLGOL function, and vice versa. The 
only differences between APL and APLGOL func- 
tions lie in the specific syntax of the function headers, 
the control structures, the use of the lamp symbol (fl) 
as a comment terminator, and the fact that APLGOL, 
like ALGOL, terminates statements with a semicolon. 
Fig. 1 contrasts an APL function with its equivalent 
APLGOL function, illustrating how nearly identical 
the two functions are. 

Canonical Forms 

For run-time efficiency, it has been customary for 
APL interpreters to translate functions from character 
form into an internal form, whereupon the original 
character source is discarded. Subsequent requests 
for display of the functions are satisfied by translating 
the internal form back to a canonical character form. 
APL programmers have become accustomed to this 
canonical form of their programs being slightly dif- 
ferent from what they originally input, in that un- 
necessary blanks have been compressed out, labels 
"undented", and the formats of numeric constants 
perhaps changed. The short function shown below 
illustrates how the original and canonical forms may 
differ for APL: 

Original APL 

[0] R^ PART PERCENT WHOLE 

[1] R ^1E2 x PART^ WHOLE 
Canonical APL 

[0] R^PART PERCENT WHOLE 

[1] R^lOOxPART^WHOLE 
In similar fashion, APLGOL translates to internal 
form and back-translates to a stylized canonical form. 
However, APLGOL canonical form may be markedly 
different from the original. APLGOL can be input 
free-form with many statements per line, but the ca- 
nonical form always has one statement per line, with 
indenting for each layer of nesting. As Fig. 2 shows, 
the canonical form of this function offers the advan- 
tage of making the control structures more obvious by 
indenting the IF-THEN-ELSE statements. 

One consequence of the APLGOL control structures 
is that the keywords of these structures (IF, THEN, etc.) 
are reserved and cannot be used as variable or func- 
tion names in APLGOL functions. This is not usually 
a severe limitation to the programmer. 

Important Design Considerations 

APLGOL is a fully-supported language, not an 
add-on to APL. The decision was made early in the 
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Original APLGOL 

[ o] PROCEDURE A CONFORMS B;IF (V/l = (x/pA),x/pB)THEN 

[ l] 'CONFORMABLE - SCALAR/UNIT EXTENSION' ELSE IF (ppA)=ppB 

[ 2] THEN IF (pA) A.=pB THEN'CONFORMABLE - SAME SHAPE' ELSE 

[ 3] 'NOT CONFORMABLE - LENGTH ERROR' 

[ 4] ELSE 'NOT CONFORMABLE - RANK ERROR 1 ; 

[ 5] END PROCEDURE 

Canonical APLGOL 

[ 0] PROCEDURE A CONFORMS B; 
[ l] IF (v/l = (x/pA),x/pB) THEN 

'CONFORMABLE - SCALAR/UNIT EXTENSION' 
ELSE 

IF (ppA)=ppB THEN 
IF (pA)A.=pBTHEN 

'CONFORMABLE - SAME SHAPE' 
ELSE 

'NOT CONFORMABLE - LENGTH ERROR' 
[ 9j ELSE 

[10] NOT CONFORMABLE - RANK ERROR'; 

[ll] END PROCEDURE 



[2] 
[3] 
[*] 
[«] 
[6] 
[7] 

[»] 



Fig. 2. User inputs in APLGOL are translated to an internal 
form and back-translate to a canonical form. The canonical 
form makes the control structures more obvious by indenting. 



design stages that it was to be as convenient to use as 
APL and should require no extra steps for the pro- 
grammer. It was to suffer no significant speed or space 
penalties, but should offer itself as a viable alternative 
to programming in APL. 

One important design decision was to use the same 
dynamic incremental compiler for both APL and 
APLGOL (see article, page 17). Once a function has 
been translated to internal form (S-code), its incre- 
mental compilation and execution is handled by a 
single mechanism that is common to both languages. 
The most obvious payoff from this approach is that 
only one such system needed to be implemented, 
resulting in lower development costs than if two 
separate compilers had been written. A second, less 
obvious advantage is that this guarantees that there 
are no insidious semantic differences in the way each 
language evaluates its expressions. That is, an ex- 
pression like +/" gives the same result (DOMAIN 
ERROR in some systems, including ours; in other 
systems) in both languages. Finally, it guarantees that 
the execution speed of both languages is the same, 
except in functions dominated by branching over- 
head. In these cases APLGOL tends to be slightly 
faster, because it generates more efficient branching 
code. APLGOL branches don't have to be range- 
checked at run time as APL branches do, since all 
APLGOL branches are generated and guaranteed in- 
range by the character-to-internal translator when the 
function is created. 

These considerations continually influenced the 
design of APL\3000, most often having the effect of 



complicating internal code assignments, data struc- 
tures, and support routines. The result, however, is a 
system that honestly supports both APL and APLGOL 
without noticable favoritism of either. J? 
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APIA3000 Summary 



Primitive Functions and Operators 


Monadic 




Dyadic 


IDENTITY 


+ 


ADDITION 


NEGATE 


- 


SUBTRACTION 


SIGNUM 


X 


MULTIPLICATION 


RECIPROCAL 


+ 


DIVISION 


EXPONENTIAL 


. 


POWER 


NATURAL LOGARITHM 


® 


GENERAL LOGARITHM 




A 


AND 




V 


OR 




A 


NAND 




V 


NOR 


NOT 


~ 






< 


LESS THAN 




< 


LESS THAN OR EQUAL 




= 


EQUAL 




# 


NOT EQUAL 




i 


GREATER THAN OR EQUAL 




> 


GREATER THAN 


ROLL 


? 


DEAL 


PI TIMES 


o 


CIRCULAR FUNCTIONS 


CEILING 


1 


MAXIMUM 


FLOOR 




MINIMUM 


ABSOLUTE VALUE 


1 


RESIDUE 


FACTORIAL 


: 


BINOMIAL 


SHAPE 


p 


RESHAPE 




T 


TAKE 




J. 


DROP 


AXIS (AUXILIARY) 


n 


INDEXING 


INDEX GENERATOR 


i 


INDEX OF 


REVERSE 


§ or e 


ROTATE 


TRANSPOSE 


Si 


GENERAL TRANSPOSE 


REDUCTION 


/or / 


COMPRESSION 


SCAN 


Nor \ 


EXPANSION 


RAVEL 




CATENATE 



System Variables 



GRADE UP 
GRADE DOWN 



EXECUTE 
FORMAT 
MATRIX INVERSE 



e MEMBERSHIP 

1 DECODE 

T ENCODE 

i EXTENDED EXECUTE 

* EXTENDED FORMAT 

MATRIX DIVISION 

GENERALIZED INNER PRODUCT 
GENERALIZED OUTER PRODUCT 



Overstrike Characters 

Formed by striking one key, backspacing, strik- 
ing other key. Order Immaterial. 



mbol 


Made with 


Symbol 


Made with 


81 


* 






* 


c 1 


R 


n ° 






A 


A ~ 


e 


o - 






Si 


c \ 


V 


V ~ 


/ 


/ - 


k 


A 


\ 


\ - 


1 


V 


i 


l - 


A 


A 


T 


T • 






h 


D + 


Z 


Z 


□ 


Q' 


A 


A _ 



Da 


Alphabet Characters 


QLX Latent Expression 


Dai 


Account Ir 


formation 


QN Null Character 


Dal 


APLGOL Assertion Level 


[]PP Print Precision 


Dav 


Atomic Vector 


□PW Print Width 


Db 


Backspace 


Character 


GR Carriage Return Character 


Dct 


Comparison Tolerance 


GRL Random Link (Seed) 


Dd 


Digit Characters 


DSN Stack Names 


De 


Escape Character 


[]T Horizontal Tab Character 


Dht 


Horizontal Tab Positions 


[]TT Terminal Type 


Do 


Index Orig 


in 


□TS Time Stamp 


Dl 


Line-Feed Character 


QVM Virtual Memory Characteristics 


Dla 


Language 




QWA Workspace Area Used 


Dlc 


Line Counter 


Gwi Workspace Identification 






System Functions 


Result 


Syntax 


Name 


CM^ 




□CR CV 


Canonical Representation 


NS- 


{CV} 


□CSE NV 


Capture Stack Environment 


AV<- 


NSV 


□CV AV 


Convert 


NS- 




□dl ns 


Delay 


BV^ 




Qex cvm 


Expunge 


CV^ 




Dfx cvm 


Function Establishment (Fix) 


NM^ 




Qmv cv 


Monitor Values 


NV<- 




□nc cvm 


Name Classification 


CM^ 


{CV} 


Qnl NSV 


Name List 


BV^ 




Oqm cv 


Query Monitor 


BV^ 




□qs cv 


Query Stop 


BV^ 




Dqt cv 


Query Trace 


NV^ 




□RSE NV 


Release Stack Environment 


NV^ 


{NV} 


Qrm cv 


Reset Monitor 


NV^ 


{NV} 


□rs cv 


Reset Stop 


NV^ 


{NV} 


□rt cv 


Reset Trace 


NV^ 


{NV} 


□SM CV 


Set Monitor 


NV^ 


{NV} 


Qss cv 


Set Stop 


NV^ 


{NV} 


Dst cv 


Set Trace 


NM^ 


{bvm} 


□SVC CVM 


Shared Variable Control 


NV^ 


{cvm} 


□SVO CVM 


Shared Variable Offer 


NV^ 




□SVR CVM 


Shared Variable Retract 


CM^- 




Qsvq CV 


Shared Variable Query 


CV~ 




Qvr CV 


Vector Representation 


Notes 








AV: 


Arbitrary Vector 


BM: Boolean Matrix 


BY: 


Boolean 


Vector 


CM: Character Matrix 


CV: 


Character Vector 


CVM; Character Vector or Matrix 


NM: 


Numeric 


Matrix 


NS: Numeric Scalar 


NSV: 


Numeric Scalar or Vector 


NV: Numeric Vector 


{a}: 


a Is Opt 


onal 





Miscellaneous 

Negative Constant Indicator 

Character Constant Delimiter 
«- Assignment 
-» Branch 

G Evaluated Input, Output 
D Literal Input, Prompting Output 
( ) Grouping 
<f> Statement Separator 
; Statement Separator(APLGOL), List Separator 

Label Indicator 
ft Comment Delimiter 



APLGOL Control Structures 

ASSERT INTEGER EXPRESSION: BOOLEAN EXPRESSION 
BEGIN STATEMENT LIST END 

CASE INTEGER EXPRESSION OF INTEGER CONSTANT 
BEGIN 

CASE LABEL: STATEMENT; 

CASE LABEL: STATEMENT; 

CASE LABEL: STATEMENT; 
{DEFAULT: STATEMENT;} 
END CASE 
EXIT {EXPRESSION} 
FOREVER DO STATEMENT 
HALT {EXPRESSION} 

IF BOOLEAN EXPRESSION DO STATEMENT 
IF BOOLEAN EXPRESSION THEN STATEMENT 
ELSE STATEMENT 
ITERATE: CONTROL STRUCTURE NAME LIST 
LEAVE: CONTROL STRUCTURE NAME LIST 
NULL 

PROCEDURE HEADER; STATEMENT LIST END PROCEDURE 
REPEAT STATEMENT LIST UNTIL BOOLEAN EXPRESSION 
RESTART: CONTROL STRUCTURE NAME LIST 
WHILE BOOLEAN EXPRESSION DO STATEMENT 



Notes: 

{«}: a Is Optional 

CONTROL STRUCTURE NAME LIST: List of Control Structure Names 

among CASE, FOREVER, IF, PROCEDURE, REPEAT, or WHILE. 

E.g.: IF.CASE 
HEADER: Standard APL Function Header, except that Local Variables 

Are Preceded by a Comma instead of a Semicolon. 
STATEMENT: One of the Above Control Structures, or an APL Expression. 
STATEMENT LIST: One or More Statements, Each Terminated by a Semicolon. 
Comments Have the Form: n COMMENT TEXTfl 



Editor Commands 

A{DD} Allows Entry of New Text 

BJRIEF} Changes Messages to Brief Mode (Short) 

C{HANGE} Substitutes One String for Another 

CO{PY} Copies Text from One Location to Another 

CU{RSOR} Changes the Line Pointer 

D{ELETE} Deletes Lines in the Edit Text 

DELT{A} Changes the Line Increment 

END Exits Editor, Making Text into a Function 

F{IND} Locates a String in the Text 

HJELP} Prints Information about Editor Commands 

L{IST} Prints Lines of Text 

LOCK Similar to END, but Locks the Function 

MAT{RIX} Exits Editor, Creating a Character Matrix 

M{ODIFY} Modifies the Contents of a Line 

QUIT Exits Editor, Discarding the Changes 

R{EPLACE} Replaces Lines of the Text 

RESJEQUENCE} Renumbers and Moves Text Lines 

U{NDO} Negates the Effects of the Last Commands 

VEC{TOR} Exits Editor. Creating a Character Vector 

VER{BOSE} Changes Messages to Verbose Mode (Long) 



System Commands 

Turns Binding Messages ON or 

OFF 
Obtains New, Clean Workspace 

(WS) 
Leaves APL, Saving WS in Work- 
space CONTINUE 
Obtains Part or All of a Stored WS 
Sets the Execution Stack Size 
Deletes a Stored WS 
Enters Editor, Working on OBJECT 

NAME 
Deletes Objects in NAME LIST 

from Active WS 
Leaves APL 
Lists Stored Files 
Lists Functions in Active WS 
Prints Information about System 

Commands 
Specifies Default Language Pro- 
cessor 
Lists Stored APL Workspaces 
Makes a Copy of a Stored WS the 

Active WS 
Break from APL to MPE Command 

Interpreter 
Leaves APL 

Like COPY, but Doesn't Replace 
Objects 
) RESET {ENVIRONMENT NUMBER} Sets an Environment to the Empty 

Environment 



)BIND 

(CLEAR 

(CONTINUE 

)COPY WSID {NAME LIST} 
(DEPTH {INTEGER} 
(DROP WSID 
(EDIT {OBJECT NAME} 

(ERASE NAME LIST 

(EXIT 

) FILES {GROUP {.ACCOUNT}} 

)FNS {LETTER} 

(HELP {COMMAND NAME} 

)LANGUAGE {APL OR APLGOL} 

)L1B {GROUP {.ACCOUNT}} 
)LOAD WSID 

(MPE 

(OFF 

)PCOPY WSID {NAME LIST} 



(RESUME 

)SAVE {WSID} 

(SI {ENVIRONMENT NUMHER} 

(SIV {ENVIRONMENT NUMBER } 

(TERM {TERMINAL TYPE} 
(TERSE 

(TIME 

(VARS {LETTER} 

(VERBOSE 



Resumes Execution of Suspended 

Function 
Stores the Active Workspace 
Prints the State Indicator 
Prints the State Indicator Stack, 

with Local Variables 
Sets the Terminal Type 
Sets Messages to Terse Mode 

(Short) 
Turns Calculator Mode Timing 

ON/OFF 
Prints the Variables in the Active 

WS 
Sets Messages to Verbose Mode 

(Long) 
Changes the Active WS's Name 



(WSID {WSID} 
Notes: 

{a}: a is optional 

WSID: Workspace Identification 

TERMINAL TYPE: One of AJ. ASCII. BP, CDI, CP, DM, GSI, or HP 

All Commands May Be Abbreviated. 

Circular Functions 

R «- A c B 



Note: 



a Is Optional. Commands May Be Abbreviated. 



1 


R 


A 


R 


7 


arc tanh B 


1 


sin B 


6 


arc cosh B 


2 


cos B 


5 


arc sinh B 


3 


tan B 


4 


( -1+B*2)*.5 


4 


(1 + B*2)*,5 


3 


arc tan B 


5 


sinh B 


2 


arc cos B 


6 


cosh B 


1 


arc sin B 


7 


tanh B 





(1-B*2)*.S 







SPECIFICATIONS AND FEATURES 

APL 3000 (Language Subsystem 32105A) 



APLX3000 is a language subsystem that runs under the control of Multi- 
programming Executive (MPE) on the HP 3000 Series II Computer. 
COMPATIBILITY: APLSV compatible, including system functions and variables, 
shared variable mechanism, Format (*), Execute (i), Scan( .), and Matrix 
Inversion and Division (0). 
FILE SYSTEM: Full access to the Multiprogramming Executive (MPE) file system 
allows private or shared files via the Shared Variable mechanism, communica- 
tion with other language subsystems, access to peripheral devices (line printers, 
card readers, magnetic tapes, discs, etc.). 
APLGOL: An alternate language that provides modern ALGOL-like control struc- 
tures in an APL environment. IF-THEN-ELSE, BEGIN-END, WHILE-DO, 
REPEAT-UNTIL, CASE, and ASSERT are among the constructs available. 
EDITOR: Full function and text editing facilities are provided for by a powerful 
new editor. Includes features never before available to APL programmers, among 
them the ability to create and edit matrices and vectors. Provides such com- 
mands as CHANGE, COPY, FIND, RESEQUENCE, and UNDO, as well as 
a HELP facility for the novice or occasional user. 
CONCEPTUAL DATA TYPES: Character and Numeric. 

ACTUAL DATA TYPES: APL automatically chooses the appropriate internal 
representation for data from the following types: 
CHARACTER: represented by 8-bit codes following the code assignments out- 
lined by GAV. Codes include lower-case ASCII alphabetics. control codes. 
BIT: values and 1 packed 16 per machine word for data of rank 1 (vector) or 

greater (array). 
INTEGER: integer values within the range -32768 to 32767 are stored as 16-bit 

signed integers. 
3EAL: real values 
floating point numbers. 16 decimal digit accuracy. 
MAXIMUM ARRAY RANK: 63 dimensions. 
MAXIMUM ARRAY SIZE: 32,767 elements. 

ARITHMETIC PROGRESSION VECTORS: Integer vectors that can be de- 
scribed by the form A +B x :C are stored as Arithmetic Progression Vectors 
(APV's), which require no data areas. 
SHARED DATA AREAS: Variables of rank 1 (vector) or greater can share the same 
data areas, avoiding multiple copies of the same data. Shared data areas are 
duplicated only if one of the sharing variables attempts to change its data. 
WORKSPACE SIZE: Limited only by the amount of on-line disc storage available. 
Initial size: 32,767 bytes. Automatically made larger as necessary. Practical 
limit: 400,000,000 bytes. 
TERMINAL SUPPORT: Accepts terminals, with or without an APL character set, 
that use a standard ASCII interface at speeds from 110 to 2400 baud. Pro- 
visions made for both bit and character pairing terminals. Special support 
given to the HP 2641 A Display Station to take advantage of its special features. 
The following other terminals have been tested: Anderson Jacobson 630, 
Computer Devices Teleterm 1030, Data Media Elite 1520, Gen-Corn System 
Model 300. 
ENVIRONMENT: Runs as a standard subsystem under control of Multipro- 
gramming Executive (MPE). Allows batch APL jobs, simultaneous use of 
five other languages (BASIC, COBOL, FORTRAN, RPG, and SPL), networked 
access to other HP 3000s. 
SYSTEM REQUIREMENTS AND PERFORMANCE: The minimum system re- 
quired is an HP 3000 Series II with 256K bytes of memory operating under MPE II; 
for multilingual operation, at least 384K bytes of memory is needed. Operation 
with 10 or more terminals requires full memory (512K bytes). Maximum 
recommended number of simultaneous APL users is 16. 
INSTALLATION: APL -3000 includes hardware microcode and must be installed 
by a factory authorized Customer Engineer. Installation is included in the list 
price. 
ORDERING INFORMATION: 32105A APLX3000 Subsystem. Includes the 
dynamic compiler, hardware microcode, and the APL \3000 Reference 
Manual (32105-90002). All software supplied in object code form only. 
PRICE IN U.S.A.: $15,000. 

MANUFACTURING DIVISION: GENERAL SYSTEMS DIVISION 
5303 Stevens Creek Boulevard 
Santa Clara, California 95050 U.S.A. 

SPECIFICATIONS 

HP Model 2641 A APL Display Station 

General 

SCREEN SIZE: 127 mm (5 in) x 254 mm (10 in) 

SCREEN CAPACITY: 24 lines x 80 columns (1,920 character) 

CHARACTER GENERATION: 7x9 enhanced dot matrix; 9x15 dot character 

cell; non-interlaced raster scan 
CHARACTER SIZE: 2.46 mm (.097 in) x 3.175 mm (.125 in) 
CHARACTER SET: 128 character APL; 64 character upper-case Roman; 64 

character APL overstrike. (Note: the 2641A supports only one additional 



character set.) 
CURSOR: Blinking underline 

DISPLAY MODES: White on black; black on white (inverse video), blinking, half- 
bright, underline. 
REFRESH RATE: 60 Hz (50 Hz optional) 
TUBE PHOSPHOR: P4 

IMPLOSION PROTECTION: Bonded implosion panel 
MEMORY: MOS ROM: 24K bytes (program); RAM: std. 4096 bytes; 12 kilobytes 

max. (16K including max. data comm. buffer) 
OPTION SLOTS: 5 available 
KEYBOARD: Detachable, full APL/ASCII code bit-pairing keyboard, user-defined 

soft keys, and 18 additional control and editing keys; ten-key numeric pad; 

cursor pad; multispeed auto-repeat, N-key roll-over; 1.22m (4 foot) cable. 
CARTRIDGE TAPE (option): Two mechanisms 

READ/WRITE SPEED' 10 ips 

SEARCH/REWIND SPEED: 60 ips 

RECORDING: 800 bpi 

MINI CARTRIDGE: 1 10 kilobyte capacity (maximum per cartridge) 

Data Communications 

DATA RATE: 110. 150, 300, 1200, 2400, 4800, 9600 baud, and external. Switch 
selectable. (110 selects two stop bits). Operating above 4800 baud in APL 
mode may require nulls or handshake protocol to insure data integrity. 

STANDARD ASYNCHRONOUS COMMUNICATIONS INTERFACE: EIA stan- 
dard RS232C; fully compatible with Bell 103A modems; compatible with Bell 
202C/D/S/T modems. Choice of main channel or reverse channel line turnaround 
for half duplex operation. 

OPTIONAL COMMUNICATIONS INTERFACES (see 13260A/B/C/D Communi- 
cations data sheet for details): 
Current loop, split speed, custom baud rates 
Asynchronous Multipoint Communications 
Synchronous Multipoint Communications - Bisync 

TRANSMISSION MODES: Full or half duplex, asynchronous 

OPERATING MODES: On-line; off-line; character, block 

PARITY: Switch selectable; even, odd, none 

Environmental Conditions 

TEMPERATURE, FREE SPACE AMBIENT: 

NON-OPERATING: -40 to +75°C (-40 to + 167°F) 
OPERATING: to 55°C ( + 32 to + 131T) 
TEMPERATURE, FREE SPACE AMBIENT (TAPE): 

NON-OPERATING: - 1 to 60°C ( - 1 5 to + 1 40°F) 
OPERATING: 5 to 40°C (+41 to 104°F) 
HUMIDITY: 5 to 95% (non-condensing) 
ALTITUDE: 

NON-OPERATING: Sea level to 7620 metres (25,000 feet) 
OPERATING: Sea level to 4572 metres (15,000 feet) 
VIBRATION AND SHOCK (Type tested to qualify for normal shipping and handling 
in original shipping carton): 
VIBRATION: 37 mm (0.015 in) pp, 10 to 55 Hz, 3 axes 
SHOCK: 30g, 11ms, 1/2 sine 

Physical Specifications 

DISPLAY MONITOR WEIGHT: 19.6 kg (43 pounds) 

KEYBOARD WEIGHT: 3.2 kg (7 lbs) 

DISPLAY MONITOR DIMENSIONS: 444 mm W x 457 mm D x 342 mm H 

(17.5 in W x 18 in D x 13.5 in H). 

648 mm D (25.5 in D) including keyboard. 
KEYBOARD DIMENSIONS: 444 mm W x 216 mm D x 90 mm H (17.5 in W 

x 8.5 in D x 3.5 in H) 

Power Requirements 

INPUT VOLTAGE: 115 ( + 10% -23%) at 60 Hz (±0.2%) 
230 ( + 10% -23%) at 50 Hz (±0.2%) 
POWER CONSUMPTION: 85 W to 140 W max. 

Product Safety 

PRODUCT MEETS: UL requirements for EDP equipment, office appliances, 
teaching equipment; CSA requirements for EDP equipment; U.L. and CSA 
labels are applied to equipment shipped to the U.S. and Canada. 



Ordering Example 



Here is an example for ordering a 2641A Terminal with upper and lower case 
Roman character sets, line drawing character set, cartridge tape capability 
and five extra cartridges to be operated over phone lines: 
2641A APL Display Station 

-001 Adds Lower Case Roman Character Set 

-007 Adds Cartridge Tape Capability 

-013 Adds Five Mini Cartridges 

-202 Adds Line Drawing Character Set 

13232N Adds 103/202 Modem Cable— 15 ft. 
PRICE IN U.S.A.: 2641A, $4100. 2641A as above, $6115. 
MANUFACTURING DIVISION: DATA TERMINALS DIVISION 
19400 Homestead Road 
Cupertino, Calitornia 95014 U.S.A. 



16 



A Dynamic Incremental Compiler for an 
Interpretive Language 



by Eric J. Van Dyke 



A PL OFFERS THE USER a rich selection of primi- 
tive functions and function/operator com- 
posites. Powerful data structuring, selection, and 
arithmetic computation functions are provided, and 
their definitions are extended over vectors, matrices, 
and arrays of larger dimension, as well as scalars. 

Evaluation of complex expressions built from such 
terse operations is necessarily quite involved. Code 
must be generated and executed to apply primitive 
functions to one another and to data atoms, with 
whatever type checks and representation conversions 
are required. Nested iteration loops must be created to 
extend the scalar functions over multidimensional 
array arguments, and these must include data con- 
formity and index range checks. 

All of this gathering and checking of information 
concerning data/function interaction and loop 
structure — and its high overhead expense — is, in the 
typical naive APL interpreter, simply thrown away 
after the execution of a statement. This is because the 
nature of APL is dynamic. Attributes of names maybe 
arbitrarily changed by programmer or program. Size, 
shape, data type, even the simple meaning of a name 
(whether a data variable, shared variable, label, or 
function), are all subject to change (Fig. 1). Assump- 
tions cannot be bound to names at any time and be 
counted on to remain valid on any subsequent loop 
iteration or function invocation. For this reason, APL 
has traditionally been considered too unstable to 
compile. 

From this dilemma — high cost and wasted over- 
head that penalize interpretation but instability that 
prevents compilation — grew the dynamic incremen- 
tal compiler of APL\3000. 

Compile Only as Required 

The APL\3000 dynamic incremental compiler is 
an interactive compiler/interpreter hybrid. It is a 
compiler that generates and saves executable object 
code from a tree representation of each new APL 
expression for which none already exists. (In general, 
each assignment statement, branch, or function invo- 
cation is considered an expression.) It is also an in- 
terpreter that immediately evaluates every expression 
of a statement or function. Whenever possible, previ- 
ously compiled and saved code for an expression is 
re-executed. Only when absolutely necessary is new 
code generated. Thus stable expressions are com- 



piled, while those with dynamically varying attri- 
butes and those that are executed only once are, in 
essence, interpreted. The overhead of new code gen- 
eration is borne only when necessary, often only 
once. This scheme of infrequent overhead provides 
justification for costly optimizations, including the 
dragalong and beating discussed below, that lead to 
more efficient code. 

A balance between compiling and interpretation is 
accomplished through the generation and execution 
of signature code, binding instructions that are emit- 
ted before the code for an expression. Their purpose is 
to specify and check the attributes that are bound into 
the following code, that is, constraints that may not 
change if the compiled code is to be re-executed. 
Signature instructions are generated that test index 
origin (0 or 1), meaning of names (whether data vari- 
able, shared variable, or otherwise), type and dimen- 
sions of expressions (representation, size, and shape), 
access information for data (origin and steps on each 
dimension), and run-time index bounds checks. 

These signature instructions are bypassed on the 
first execution after compilation, when all assump- 
tions are guaranteed satisfied. On subsequent execu- 
tions, the signature code is used to test the validity of 
the code that follows. If these assumptions are found 
to be invalid, the code "breaks". Execution is re- 
turned to the compiler and code with a new set of 
assumptions is generated (Fig. 2). On recompilation, 
an expression is assumed unstable and a not-so- 



ANS< 



-A+B 

4 4 4 



Integer Scalar Variable 
Dyadic Primitive Function 
Integer Scalar Variable 



[A Numeric Value] 



ANSx 



Real Vector Variable 
Dyadic Primitive Function 
Character Matrix Variable 



A+B 

ttt 



[A Domain Error] 



ANS< 



Monadic User-Defined Function 
Monadic Primitive Function 
Niladic User-Defined Function 



A+B 

u 



[A Numeric Value] 



Fig. 1 . APL is dynamic. Attributes of names may be arbitrarily 
changed by the programmer or by a program. For this reason, 
APL has been considered impossible to compile. 
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Fig. 2. In APL \3000, expressions are compiled when first 
encountered. Along with the compiled code signature code/s 
generated, specifying constraints that must be met if the code 
is to be re-executed. This signature code is tested on sub- 
seguent invocations of the expression, and if the constraints 
are not met, recompilation is required. 

specific but somewhat slower and less dense form of 
code is generated. Further changes may not force a 
recompilation. 

Wait as Long as Possible; Do as Little as Necessary 

The secret to compiling efficient code is in gather- 
ing, retaining, and exploiting as much information 
about the entire expression as possible before generat- 
ing code. The more context that can be recognized, 
the more specific "smarts" can be tailored into the 
code. For this reason, the APL\3000 compiler oper- 
ates in two distinct functional passes: context gather- 
ing and code generation. 

The context gathering, or foliation, phase of compi- 
lation is a complete bottom-up traversal of the expres- 
sion tree. Fig. 3 shows an example of such a tree. 
Description information is associated with each of the 
constant and variable data nodes — the leaves of the 
tree. These descriptions are then "floated" up to in- 
teract with the parent node. Descriptions are revised 
and attached to the corresponding node as necessary 
to suit the result. This process continues as descrip- 
tions are gathered and carried up through each func- 
tion or operator node toward the root. Attached to the 
final assignment or branch node will be a context 
description for the entire expression. Fig. 4 shows the 
foliated tree for the expression of Fig. 3. 

The information created by this foliation process 
consists of a set of auxiliary description nodes at- 
tached to each node in the expression tree. Each of 
these description groups contains the attributes of the 
result of the expression to which it is attached, as 
modified by that function and those below. First in 
the set of descriptor nodes is a single RRR node, which 




Fig. 3. The tree representation of an expression. The 
APL \3000 compiler traverses this tree twice, once for. context 
gathering and once for code generation. 

describes the general structure of the current expres- 
sion: RANK (number of dimensions — for scalar, 0], 
REPRESENTATION (internal data type), and RHOs (size of 
each dimension — for scalar, there is none). Linked to 
the RRR node is a chain of DELOFF nodes , or data access 
descriptions, at least one for each non-scalar data item 
in the expression. A deloff node indicates the order 
in which an item is accessed and stored — row major, 
for example — by means of an OFFSET (origin), and a 
DEL (step) for each coordinate. Notice that these de- 
scriptions are independent of the data; storage need 
not be accessed during this foliation process. 

Frequently, data storage is shared. In such cases, 
multiple descriptors are created, perhaps with differ- 
ing access schemes. Each addresses the same shared 
area. A common form of vector data created by the 
INDEX GENERATOR function is the arithmetic progres- 
sion vector (APV). This vector may be completely rep- 
resented by its descriptor; no data area is necessary at 
all. For example, 2+3x14 requires only the descriptor: 

RHO: 4 OFFSET: 5 DEL: 3 

to represent the values 5 8 11 14. 



Dragalong and Beating 

It is the gathering and manipulation of these data- 
independent descriptors, following the dragalong 
and beating strategies developed by Abrams, 1 that 
makes possible the extensive optimizations incorpo- 
rated in APL\3000. 

Dragalong, the strategy of deferring actual evalua- 
tion as far as possible up the expression tree by gather- 
ing descriptions, avoids the naive interpreter's usual 
one-function-at-a-time "pinhole" evaluation. In- 
stead, the code for a collection of parallel functions, 
including their associated loops, can be generated 
and executed simultaneously. Fig. 5 compares naive 
with dragged code. 

Beating, the application of Abrams' subscript cal- 
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RANK 2 (Matrix) 
REPRESENTATION Real 
RHO 2 
RHO 1 3 



RANK (Scalar) 
REPRESENTATION Real 



ANS 



I RRR 1.1 



DELOFF 



OFFSET 

DEL 1 



, (RANK 1 (Vector) 



\ I HANK 1 (Vector) 

K REPRESENTATION Integer ) RRR 2 3 

' 1 RHO 2 j 




DELOFF 



OFFSET 
DEL 3 

DEL 1 1 



RANK 2 (Matrix) 
REPRESENTATION Real 
RHO 2 
RHO 1 3 



OFFSET 
DELOFF < DEL 3 

DEL 1: 1 



RANK 2 (Matrix) 
REPRESENTATION. Real 
RHO 2 
RHO 1 3 , 



OFFSET 
DELOFF { DEL 3 

DEL 1 1 



RANK 2 (Matrix) ] , 

RHO"' 5 ?™™ 1 '™ ln,eQer DEL0FF < ° EL < 
RHO 1:3 I 



RANK 1 (Vector) 
RRR < REPRESENTATION APV 
RHO0 6 



DELOFF 



/ OFFSET 1 \ 
\ DEL 1 / 



RRR 



RANK (Scalar) 
REPRESENTATION Integer 



Foliated Expression Tree for ans «— 1.1 + 2 3 p \B 



Fig. 4. Foliated expression tree results from the context gathering phase of compilation. Auxiliary 
description nodes contain the attributes of the sub-expression to which they are attached. 



cuius to a deferred expression when evaluation is 
finally required, produces the desired results for cer- 
tain APL functions by description manipulation 
alone. In such cases, the original data is shared with 
the beaten result, making it unnecessary to copy the 
data in a different form. Thus data is touched only 
when and only as much as necessary. (Data sharing is 
described in more detail in the article beginning on 
page 6.] SUBSCRIPTION, RESHAPE, RAVEL, TAKE, DROP, 
reversal, and monadic and dyadic TRANSPOSE are the 
functions to which beating optimizations may be 
applied (see Fig. 6). 

The dragalong and beating strategies can signifi- 
cantly reduce the amount of data access and storage, 



computation and looping overhead, and often tempo- 
rary storage required in the evaluation of an expression. 
An independent context gathering pass during 
compilation provides an opportunity for a number of 
specific optimizations in addition to dragalong and 
beating. For example, a pair of adjacent monadic RHO 
nodes can be recognized as a new internal RANK func- 
tion. The result is merely the rank of the argument as 
indicated by its description, eliminating the need for 
an intermediate rho vector (see Fig. 7). Similarly, 
successive CATENATE nodes can often be incorporated 
into a new multi-argument POLYCAT function, elimi- 
nating the superfluous data moves and intermediate 
storage that would normally be required (Fig. 8). 



Naive Dragged 


INITIALIZE INDEX I AND LIMIT INITIALIZE INDEX AND LIMIT 


WHILE INDEX 1 4 LIMIT DO WHILE INDEX <f LIMIT DO 


BEGIN BEGIN 


TEMPORARY [INDEX 1]^B[INDEX 1 \xC\lNDEX 1] ANS[lNDEX\^A\lNDEX] +B{lNDEX]xC[lNDEX\ 


INCREMENT INDEX 1 INCREMENT INDEX 


END END 


INITIALIZE INDEX 2 


WHILE INDEX 2 t LIMIT DO 


BEGIN 


ANS [INDEX 2 ]—A[lNDEX 2\+TEMPORARY[lNDEX 2] 


INCREMENT INDEX 2 


END 



Fig. 5. Evaluation of an expres- 
sion is deferred as long as pos- 
sible. This strategy, called drag- 
along, makes it possible to gener- 
ate and execute the code for a 
number of parallel functions simul- 
taneously, avoiding the naive in- 
terpreter's one-function-at-a-time 
evaluation. Shown here is a com- 
parison of naive with dragged 
code for ans^a+bxc. a, b, and c 
are conformable vectors. 
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Fig. 6. When evaluation is finally required, beating, or the 
application of the subscript calculus to a deferred expression, 
may produce results by description manipulation alone. Here 
take (T) and reversal (<j>) are applied to descriptions for a 
simple expression. The dragalong (see Fig. 5) and beating 
strategies can significantly reduce the computation and stor- 
age required in the evaluation of an expression. 



APL\3000's target machine is a software/firmware 
emulator implemented on the HP/3000. The instruc- 
tion set, in addition to loads, stores, and loop and 
index controlling instructions, includes a set of high- 
level opcodes that match the APL primitive scalar 
functions. Code generation from an expression fol- 
lows a recursive descent of the tree: an instruction to 
set up a storage area for the result (typically a tempor- 
ary) is emitted, followed by a reverse Polish sequence 
of data loads and operations, and finally a store into 
the result, all nested within the necessary loops. 

Any instruction that has the potential to fail carries 
within it a syllable number that provides the machine 
with a pointer to the original source in case of an 
error, allowing for recompilation on binding errors or 
message generation on user errors. 

The descriptions at the root node completely de- 
scribe all index variables and iteration loops to be 
generated. Each DELOFF node, with optimizations 
beaten in, describes the initialization (OFFSET) and 
stepping (DEL) of an index register. The loops, one for 
each dimension of the result, in general, are derived 
from the rrr in conjunction with a selected DELOFF. 
Loops are all of a basic structure: 
INITIALIZE ALL INDEX REGISTERS 
INITIALIZE LIMIT REGISTER 
WHILE CHOSEN INDEX * LIMIT DO 
BEGIN 

INITIALIZE LIMIT REGISTER 
WHILE CHOSEN INDEX * LIMIT DO 
BEGIN 

(Indexed Expression Code) 

INCREMENT ALL INDEX REGISTERS 

END 
INCREMENT ALL INDEX REGISTERS 
END 

Equality, unlike > and <, is a consistent termina- 
tion condition for loops that may run in any direction. 
For each loop, a DELOFF node is selected to serve as the 
loop-controlling induction variable. Because of their 
special uses, certain indexes are not eligible (those for 



Code Generation 

When the compiler is finally forced to materialize 
an expression — either the root has been reached, or 
the compiler can drag no farther for one reason or 
another — code is emitted. This code generation pass 
is a second independent walk of the foliated tree with 
dragged and beaten descriptions attached, this time 
from the top down, generating and saving executable 
code for the expression. By exploiting the context 
descriptions that have been gathered up the tree from 
each node, specifically tailored code can be gener- 
ated. Because APL in general deals with arrays, this 
process also usually involves the construction of 
loops. 




Fig. 7. The context gathering pass provides an opportunity 
for specific optimizations, such as recognizing a pair of adja- 
cent monadic rho nodes as the new internal rank function. 
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A Controller for the Dynamic 
Compiler 



by Kenneth A. Van Bree 



The controller for the dynamic compiler performs all of the 
tasks an interpreter for APL must perform, such as handling user 
input and editing, sequencing between lines of a function, 
calling and returning from user-defined functions, and handling 
errors. In addition, the controller handles the generation and 
re-execution of compiled code for APL statements. 

One of the guiding assumptions in the design of the controller 
was that code for a particular statement could be compiled once 
and would remain valid for many re-executions of that 
statement. This assumption was based on the observation that 
most APL programmers do not take full advantage of the 
dynamic capabilities of APL. Changes in the value or size 
(number of elements) of a variable are frequent, but changes in 
the shape or representation of a variable are rare. For this 
reason, the controller has been designed to re-execute com- 
piled code as quickly as possible, while still maintaining the 
flexibility needed to perform all the other duties related to 
controlling an interactive language such as APL. 

The controller consists of five interacting modules as shown in 
the diagram. Each module performs a subset of the duties 
related to controlling the compiler, and any module can call on 
any other module to perform a task that it cannot do itself. The 
normal flow of control for an APL expression input by the user (in 
calculator mode) is as follows: 

Text for the expression is input by the user through the user 
input and editing module. This module is in charge of all 
interactions with the user, and before control leaves this 
module, all text that the user enters is converted into an internal 
form called S-code. S-code is a compact form of the text, with 
each identifier replaced by an internal short name for easy 
reference. The actual text that the user enters is not saved, but is 
regenerated from S-code if needed. 

Once S-code has been created, control is passed to the line 
statement sequencing module, which handles the dynamic flow 
of control between lines and statements in APL. As each 
statement is executed, this module checks to see whether it has 
been executed before. If a statement has never been executed 
before, a syntax analysis is done on the S-code for that 
statement. The result of the syntax analysis is one or more syntax 
trees called D-trees. Each D-tree represents the largest part of 
an APL statement that can be guaranteed to have no side 



effects. For example, in the statement A^B+C, if C is a 
user-defined function, then the statement will be broken up into 
two trees. The first tree will materialize the function C into a 
temporary variable, and the second tree will add the results of C 
to B and assign the sum to A. 

As soon as D-trees have been created for a statement, control 
is passed to the executable code creation/sequencing module. 
Within this module, each D-tree for a statement is examined in 
sequence, and if it does not represent a function call, it is 
passed to the dynamic compiler. The compiler turns each 
D-tree into a block of executable code called E-code. The 
compiler calls the execution machine directly to execute the 
E-code that it has created. 

Once a valid block of E-code has been created from a D-tree 
the executable code creation/sequencing module is in charge 
of storing that E-code block for later reference. As each D-tree is 
compiled, the E-code block created is used to replace the 
D-tree. When all trees for a statement are compiled there will 
exist a series of E-code blocks that represent the statement. On 
subsequent executions of a statement, the E-code blocks are 
retrieved and given directly to the execution machine. If the 
code contains a non-fatal error such as a change in representa- 
tion or rank of a variable, the execution machine returns a 
non-fatal error indication to the executable code creation/ 
sequencing module, which calls the non-fatal error handler to 
correct the problem. The non-fatal error handler recreates a 
D-tree for the part of the statement affected by the non-fatal 
error. New E-code is then compiled with the non-fatal error 
corrected, and the new E-code block is saved in place of the 
one in which the error was found. 

If the executable code creation/sequencing module detects 
that a particular D-tree represents a function call, then control is 
passed to the user-defined function call and return module. If 
the line statement sequencing module detects a function return, 
it can also pass control directly to the user-defined function call 
and return module. 

If any of the other modules detects a fatal error, such as an 
undefined variable or a syntax error, control is passed directly to 
the fatal error handler. This module suspends execution, prints 
an error message for the user, and then returns control to the 
user input and editing module to wait for input from the user. 
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Fig. 8. Another optimization that 
can be effected during context 
gathering is combining succes- 
sive catenate nodes into a new in- 
ternal polycat function. 



single-element arrays that will never be incremented, 
for example, or the left indexes of COMPRESS and EX- 
PAND, which are incremented asynchronously). 

A limit for each loop, calculated as OFFSET + RHO x 
DEL (on the appropriate coordinate, from the chosen 
induction variable) plus the current induction vari- 
able, is also created in a register. Except for the outer- 
most (or only) loop limit, which may be constant, the 
limit value must be calculated at execution time. In- 
itialization values and increments for all indexes cor- 
respond to the OFFSETS and DELS of their associated 
DELOFF descriptors. Fig. 9 shows the code generated 
for a vector expression. 

A number of optimizations are performed prior to 
the generation of loops. Except for actual display, an 
expression represented as an arithmetic progression 
vector (APV) requires no evaluation loop at all; its 
description completely specifies the result. Redun- 
dant index variables, which would run in parallel, are 
shared by collecting those DELOFF nodes having iden- 
tical attributes into a single register. If, according to 
the descriptors, a loop is unnecessary, as is often the 
case with row-major compact storage, it is collapsed, 
subsumed by the next outer loop. 

In addition, certain improvements in the code can 
be made. Unlike larger data structures, in which data 
can be partially destroyed if an error is encountered, 
scalar and single-element expressions can be gener- 
ated without assignment to an intermediate tempor- 
ary variable, eliminating the setup, some use of stor- 
age area, and the resulting data swap. Occasionally, 
when the result produced from such a unit expression 
involves itself, a new data area need not be set up at 
all. Instead, the old name is retained for the result of 
the expression. Subexpressions yielding a scalar or 
single-element array within the scope of a loop can 
frequently be materialized, or assigned into a tempor- 
ary cell, outside the loop, eliminating their repeated 
evaluation. The more complex argument to an OUTER 
PRODUCT operator can similarly be constrained to an 
outer code loop, affording it less frequent evaluation. 

Hard and Soft Code 

The code generated by APL\3000 is of two types. 



Initially, hard or tight code is produced. In this style 
of code, the RHOs, OFFSETS, and DELS, as well as RANK 
and REPRESENTATION are bound into the instructions 
as constants. If this specific form of code has broken 
and a recompilation is required, more general soft or 
loose code is generated, in which only the rank and 
REPRESENTATION are bound. RHOS, DELS, and OFFSETS 
may be calculated in registers at run time. Thus the 
dimensional attributes of an array may dynamically 
change without invalidating the code again. 



SET UP STORAGE AREA FOR RESULT TEMP 
INITIALIZE STORING INDEX TO 

(OFFSET FOR ANS AND TEMP) 
INITIALIZE VECTOR ACCESSING INDEX TO 2 

(OFFSET FOR VECTOR BEATEN BY <j>) 
INITIALIZE APV ACCESSING INDEX TO 1 

(OFFSET FOR 1 3) 
INITIALIZE LIMIT TO 3 

(RHO X DEL + OFFSET + STORING INDEX) 

WHILE STORING INDEX ^LIMIT DO 
BEGIN 

LOAD APV ACCESSING INDEX 

INTEGER LOAD OF VECTOR [VECTOR ACCESSING INDEX] 
INTEGER MULTIPLY 
CONVERT TO REAL 
REAL LOAD OF CONSTANT 1 1 
REAL ADD 

REAL STORE INTO TEMP [STORING INDEX] 
INCREMENT STORING INDEX BY 1 

(DEL FOR ANS AND TEMP) 
INCREMENT VECTOR ACCESSING INDEX BY ~1 

(DEL FOR VECTOR BEATEN BY (()) 
INCREMENT APV ACCESSING INDEX BY 1 

(DEL FOR 13) 
END 
SWAP TEMP INTO ANS 



Fig. 9. When the compiler can drag no farther it emits code. 
The code generation phase is a second traversal of the (now 
foliated) expression tree. Because APL in general deals with 
arrays, code generation usually involves the construction of 
loops. Shown here is the code generated for the expression 
ans<-i.i +($vector)xi3. vector is an integer vector of length 3. 
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Hard 


Soft 


SET UP STORAGE AREA FOR RESULT TEMP 


SET UP STORAGE AREA FOR RESULT TEMP 


INITIALIZE STORING INDEX TO 


INITIALIZE STORING INDEX TO 


INITIALIZE VECTOR ACCESSING INDEX TO 2 


INITIALIZE VECTOR ACCESSING INDEX TO 


INITIALIZE LIMIT TO 3 


(RHO - 1 ) X DEL + OFFSET FROM VECTOR 


WHILE STORING INDEX A LIMIT DO 


INITIALIZE VECTOR ACCESSING INCREMENT TO 


BEGIN 


~DEL FROM VECTOR 


LOAD 1 


INITIALIZE LIMIT TO RHO FROM VECTOR 


LOAD VECTOR[VECTOR ACCESSING INDEX] 


WHILE STORING INDEX t LIMIT DO 


ADD 


BEGIN 


STORE INTO TEMP[STORING INDEX] 


LOAD 1 


INCREMENT STORING INDEX BY 1 


LOAD VECTOR [VECTOR ACCESSING INDEX] 


INCREMENT VECTOR ACCESSING INDEX BY ~1 


ADD 


END 


STORE INTO TEMP]STORING INDEX] 


SWAP TEMP INTO ANS 


INCREMENT STORING INDEX BY 1 




INCREMENT VECTOR ACCESSING INDEX BY 




VECTOR ACCESSING INCREMENT 




END 




SWAP TEMP INTO ANS 



Fig. 10. Code generated is of two 
types. Initially, hard code is pro- 
duced. If this code later breaks, 
more general soft code is gener- 
ated. Shown here is hard versus 
soft code for the expression 
ANS^i'ivECTOR) + 1. vector is an in- 
teger vector of length 3. 



For this more flexible form of instruction a price is 
paid in terms of speed and code bulk, but this over- 
head cost rarely approaches that of an entire recompi- 
lation every time a RHO, OFFSET, or DEL changes. 
Notice that RANK and REPRESENTATION must always be 
bound hard. RANK, which specifies the maximum 
number of loops to be generated, must have a constant 
value at compile time, representation must be 
known to determine the data type of the instructions 
issued. A change in either of these attributes always 
forces a new compilation. 

Fig. 10 compares hard and soft code emitted for a 
vector expression. 
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Extended Control Functions for 
Interactive Debugging 

by Kenneth A. Van Bree 



Several system functions facilitate debugging and program 
development in APL. Using the function Dss (set stop) it is 
possible to stop on any or each line of a function or on return 
from the function. The Dst (set trace) function allows the last 
result calculated on a line to be displayed along with the function 
name and line number. This is helpful for observing program 



flow. The Dsm (set monitor) function allows the user to monitor 
the number of times that a function and/or line has been exe- 
cuted, along with the amount of CPU time spent in each line, and 
the total CPU time spent in the function. These functions can be 

(continued on page 24) 
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used to determine where the majority of the CPU time is being 
spent on a particular problem and which lines of a program have 
never been executed. All of the monitoring facilities can be 
turned on or off and queried under program control. 

One reason that program development is so easy in APL is 
that the entire power of APL is available to the user during 
program debugging. When the APL system detects an error in a 
user program (for example, an attempt to read a variable that 
hasn't been given a value), the program is halted and an error 
message is written on the user terminal. The error message tells 
the user the type of error (a value error in this example) along 
with a pointer to where the error was detected. The APL system 
then returns control to the terminal so the user can try to correct 
the error. At this point the state indicator (SI) may be displayed. 
The state indicator is a pushdown list (i.e., stack) of all the 
user-defined functions that have been called but have not yet 
completed execution. The state indicator displays not only the 
names of the functions that have been called, but also the line 
number on which execution was suspended. In addition, a list of 
all the local variables can be obtained for each function that has 
been called but not completed. The function in which the error 
was found is the topmost entry on the SI and is called a sus- 
pended function. Other functions on the SI are called pendant 
functions. 

While computation is suspended, the user has the full power 
of APL available to him for debugging. The suspended function 
(or any other function that is not pendant) may be edited, and 
any variable that is available within the suspended function may 
be interrogated or redefined. A new computation may be started 
by calling another function, or in most cases the suspended 
computation may be resumed from the line at which it was 
suspended or any other line. If for some reason the user does 
not wish to fix the error, the SI can be cleared, or the entire 
workspace including the SI can be saved for later reference. 

The flexibility and power available to the user during debug- 
ging make it possible to detect and correct multiple errors 
during the course of the computation. This means that programs 
often run to completion the first time they are called, because 
most errors can be fixed as they are detected. A recent study of 
APL in Europe 1 showed that the conciseness of APL coupled 
with its ease of debugging produced a 3:1 improvement in 
programmer productivity over such languages as PL/I and 
COBOL. 



In this environment the value of variable v is whatever has been 
assigned within function g. The value of v within function f has 
been shadowed (by the local variable v within g) and is not 
accessible within the current function. All names accessible 
from function g make up the environment of g, and the local 
variable v of function f is not in the environment of g. Further- 
more, it is not possible to resume execution of function f without 
first completing function g, since the SI operates strictly on a 
last-in-first-out basis. 

Through the use of the extended control functions of 
APL \3000 it is possible to access variables and resume execu- 
tion in environments other than the current environment. The 
concept of multiple environments is not new, 2 but it has never 
been implemented in APL before. APLX3000 allows up to 16 
environments to be available at one time. Each environment has 
its own state indicator, and control can be passed from one 
environment to another through the use of the extended execute 
(i) function. Although the normal SI in APL obeys a strict stack 
discipline, the environments of APL\3000 may create one or 
more computation trees. This allows the creation of environ- 
ments that share a portion of their SI. When this happens, it is no 
longer possible to maintain a stack discipline for the SI, and a set 
of pointers must be maintained that links each function call to its 
calling function. The extended control functions maintain a 
stack discipline for the SI unless the user explicitly calls for a 
tree-like control structure. The overhead paid for the extended 
control capability is minimal unless it is invoked by the user. In 
the above example, the environment within function f can be 
captured by using the system function Dcse (capture stack 
environment). 



F[2] 



Dcse 

)SIV 



n Capture second function name on SI 
n The environment number is 1 
n Display the SI for environment 1 



Environment 1 now shares a part of its SI (namely the function 
f and its local variable v) with the current environment displayed 
earlier. Any arbitrary expression can be evaluated in the en- 
vironment of function f through the use of the extended 
execute function. For example, the variable v within function f 
may be assigned the value 3 as follows: 

1t'V«-3' 



Extended Control Functions 

The state of an APL computation can be displayed at any time 
by interrupting the computation (by sending the attention 
character) and displaying the state indicator through the use of 
the commands ;si or isiv. The state indicator shows all of the 
functions that have been called but have not yet completed 
execution, along with the variables that are local to those func- 
tions. The current environment consists of the variables that can 
be accessed within the topmost function on the stack, along with 
the chain of control represented by the function calls that ap- 
pear on the SI. Normally, within APL, any computation must be 
done in the current environment. For example, if the function f 
(which has local variable v) calls function g (which also has local 
variable v), and computation is suspended within g, the SI might 
appear as follows: 



)SIV 
G[3]. V 

F[2l V 



Evaluating an expression in environment 1 (or any other envi- 
ronment) is equivalent to evaluating the expression in calculator 
mode with execution suspended in that environment. Execution 
can be resumed within function f by evaluating an expression 
that results in a branch. For example: 

1i'->2' 

The extended control functions in APL\3000 can be used for 
purposes other than debugging. Since environments can be 
captured (using Gcse) and released (using Qrse) under program 
control, it is possible to implement such advanced pro- 
gramming concepts as backtracking, co-routines, and so on, 
which have been difficult or impossible to implement in APL 
before. 
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CRT Terminal Provides both APL and 
ASCII Operation 



by Warren W. Leong 



MODEL 2641A APL DISPLAY STATION (Fig. 1) 
is a special CRT terminal designed to serve as 
the principal user interface for APL \3000. APL opera- 
tion plus extensive data communications capabilities 
allow the terminal to be used with APL interpreters/ 
compilers that exist on a variety of computer systems, 
especially the HP 3000. ASCII operation is provided 
to retain compatibility with HP 2640-Series CRT 
Terminals. 

The 2641A provides a superset of the functions 
available with the 2645A Display Station. These in- 
clude dual cartridge tape units, extended editing fea- 
tures, extended data communications, modular 
firmware implementation, and eight user-defined 
soft keys. A new, faster microprocessor provides the 
control for the standard as well as the extended fea- 
tures. 



APL Features 

Major features of the 2641A APL Display Station 
are: display of the APL character set, display of the 
APL overstrike character set* , display of APL under- 
lined characters, and non-destructive spaceover. 
These features are accessible during the terminal's 
APL mode. 

The high-resolution display of 2640 Series Ter- 
minals 1,2 provides a clear and easily readable ren- 
dition of the standard APL characters as well as the 
more intricate overstrike characters (Fig. 2). There are 
two separate APL character sets: a 128-character APL 
graphics set and a 64-character APL overstrike 

* Many APL primitive functions are called by striking one APL symbol, then backspacing and overstrik- 
ing the first symbol with a second symbol. The combination forms a new APL symbol. The APL 
overstrike character set makes it possible for the 2641A to display such combinations of basic APL 
symbols. 




Fig. 1. Model 2641 A APL Display 
Station is designed to serve as the 
principal user interface for 
APL\3000 and other APL sys- 
tems. It has both APL and ASCII 
modes of operation. 
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Fig. 2. Standard 2641 A character sets are the 128-character 
APL set, a 64-character APL oversthkeset, anda64-character 
upper-case Roman set. An optional fourth character set may 
be a mathematical symbol set, a line drawing set, a large 
character set, or a user-designed set. 

graphics set (Fig. 3). Each set is programmed into 
bipolar ROMs. The APL graphics set follows com- 
monly accepted industry standard code assignments. 
The APL overstrike graphics set is used internally by 
the terminal to display the overstrike characters and 
its code assignment is dependent on terminal re- 
quirements. As each valid overstrike keystroke se- 
quence is completed the proper overstrike character 
is displayed on the screen. However, the actual over- 
strike character sequence is transmitted to the com- 
puter when in character mode or is stored in the 
display memory for later transmission when in block 
mode. 

The 2640 Series Terminals can support up to four 
independent character sets. Since the 2641A APL 
Terminal includes as standard the APL set, the APL 
overstrike set, and the ASCII set, it has room for one 
additional character set. Currently this additional set 
can be a mathematical symbol set, a line drawing set, 



a large character set, or a set of the customer's own 
design. 

The keycaps have APL legends on their top faces 
and ASCII legends, when they differ, on the front 
faces (Fig. 4). This allows unambiguous operation 
whether operating in APL or ASCII mode. The 
keyboard code assignment is bit pairing* , rather than 
typewriter pairing*, to retain compatibility with the 
2640B and 2645A Terminals. The shift (zero) posi- 
tion is re-assigned to mean A in APL and in ASCII; 

this provides full APL compatibility for users when 
switching between bit and typewriter pairing layouts. 

Firmware 

The controlling feature of the 2641A APL Display 
Station is the firmware, or microprograms stored in 
ROM. All of the characteristics of the terminal are 
defined by microprogramming the internal micro- 
processor. These characteristics include switch selec- 
tion or computer selection via escape sequence of the 
two operating modes, APL or ASCII, overstrikes that 
are recognized by the terminal, block transfers of APL 
program and data statements, and editing features 
during APL mode. 

The first consideration was how to integrate the 
APL operational requirements into the base product, 
the 2 645 A. Since many of the features of APL were 
distinctly different from normal operation, it made 
sense to define an APL mode for APL operations. In 
APL mode the APL character set is normally dis- 
played instead of the ASCII character set. Any attempt 
to overstrike an APL character results in the display of 
a character from the overstrike set. Underlining of 
APL characters is done by means of shift F. Block 
transfers (via the ENTER key) take into account the 
overstrike character set and decompose these into 
APL characters separated by a backspace control 
code. 

APL systems recognize several overstrikes. With 

'Bit pairing: shift codes differ from unshift codes by one bit. 
Typewriter pairing: codes follow an industry standard for certain typewriter terminals. 
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Fig. 3. Standard 2641A charac- 
ter sets. 
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Fig. 4. 2641 A keys have APL legends on top and ASCII 
legends, when they differ, on the front faces. 



the 2641A, these overstrikes can be done at any time 
or in any order. Overstriking poses several complica- 
tions for a raster-scan CRT terminal that dynamically 
allocates its memory and uses separate graphics sets 
for the normal and overstrike characters. An APL user 
may type several characters, then backspace to the 
beginning of the line and overstrike the required 
characters, or the user may complete each overstrike 
before proceeding to the next character. Backspacing, 
using the backspace key, does not delete characters 
previously entered and forward spacing using the 
space bar does not erase characters that are being 
spaced over. 

The basic algorithm for overstrikes directs the ter- 
minal to monitor each byte that it writes to the dis- 
play. In APL mode, the terminal checks the current 
and new characters being typed in the same display 
position and determines whether the new character 
just overwrites the old (only when the old character is 
a blank), whether the old character is replaced by a 
new character from the overstrike set, or whether the 
old character remains unchanged (the new character 
is a blank). Overstrikes are allowed only in APL 
character fields. If the cursor is in a non-APL field, 
such as Roman, then the terminal performs ASCII 
operations rather than APL operations, although the 
operating mode is APL. 

When the old and new characters form a valid over- 
strike such as and ., then the composite ! is dis- 
played. If an invalid pair is overstruck, then an OUT 
character is displayed, providing a clear indication 
that an error has been made. 

The underline overstrike (shift F) for APL is nor- 
mally restricted by APL systems to the alphabetic 
characters and a few of the special characters. The 
2641A can underline any APL character. The under- 



line overstrikes are not a part of the character ROMs. 
Instead, the underline feature of the terminal's dis- 
play enhancement section is used to simulate the 
underline overstrike. 

The underlining process begins when an APL 
character is displayed and the cursor is repositioned 
to the character. When the underline character (shift 
F) is typed, the firmware provides the proper en- 
hancements to underline the character. 

Data Transfer 

All display information, overstrikes, and under- 
lines can be stored on the cartridge tape units, printed 
on a printer, or block transmitted to a computer sys- 
tem. 

Block transfers during APL mode, from the display 
or the tape units, take into account the overstrike set 
and underline enhancements. In the case of over- 
strikes, the code from the overstrike ROM is used as 
an index into a look-up table for the two components 
of the overstrike. These two components are then 
transmitted with a backspace separating them. The 
underlined characters are transmitted with the proper 
codes: the character, then backspace, then underline. 
The OUT character is treated as a special case and 
causes five characters to be output: backspace U 
backspace T. 

Two types of printers are available for APL: bit 
pairing or typewriter pairing. Distinguishing the two 
are the code assignments of 19 of the characters. The 
2641A allows the user to select either translation 
when directing APL data to a printer. 

User-Defined Soft Keys 

The 2641A has eight special-function user-defin- 
able soft keys, fi through f8. These keys hold up to 
80 ASCII characters that are specified by the user. 
This specification may be done interactively, with the 
old contents displayed while updates are done. The 
specification may also be done by escape sequence 
from a computer system or from the optional car- 
tridge tape units. 

After logging onto an HP/3000 Computer System 
having an APL\3000 subsystem, the user specifies 
the terminal type to be a 2641A by means of the 
)TERM HP command, and the system downloads the 
soft keys with the following commands: 



Command: 
Key: 

Command: 
Key: 



JRESUME )SI 

fl f2 

ATTN JEDIT 

f5 f6 



)FNS 
f3 



JVARS 
f4 



JLOAD )SAVE 
f7 f8 



Now the user can invoke frequently typed system 
calls with a single keystroke. For instance, to edit a 
function named apli, the user can press f6 to call the 
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777 
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system editor, then type APLi, followed by RETURN, , 
and be ready to edit. The user may also redefine these 
soft keys very simply. 

Key fs contains the ATTN command, which is useful 
during line editing. Suppose the user has typed a line 
of data but notices a mistake. To correct the error, 
the user first backspaces the cursor to the incorrect 
character: j 

ABCFE 
Using the 2641 A and APL\3000, the user then hits 
ATTN, which causes the APL terminal driver to send 
an escape sequence to clear the rest of the line: 

ABC _ 
The user continues typing from this point to complete 
the data statement: 

ABCDE _ 
The traditional method of editing is to position the 
cursor under the incorrect character, then send a line- 
feed to the computer and type the correct characters, 
producing a display like: 

ABCFE 
DE 
Note that the display can be confusing to read if 
several corrections have to be made in this manner. 
However, both methods of correction are allowed by 
the subsystem and the 2641A. 

Extended Features 

Editing features have been expanded to include 
character wraparound when the terminal is doing 
character delete or insert operations. Left and right 
margins may also be set. Extended I/O operations 
with the cartridge tape option include write, back- 
space, read, data comparisons, and data logging. 

The data communications facility allows data rates 
up to 9600 baud, and multipoint capabilities that 
allow up to 32 terminals to share a single communi- 



cations line. Self-test has been expanded to allow 
testing of the optional cartridge tapes and associated 
electronics as well as the multipoint communica- 
tions option, cabling, and terminating instrumenta- 
tion. Multipoint communications can even be tested 
up to the remote modem from the terminal keyboard. 
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